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1.0 BACKGROUND (Chart 1) 

Since 1985, the Software Engineering Laboratory (SEL) has been 
studying the impact of Ada and Ada-related technologies on the 
software development of production projects within the Flight 
Dynamics Division (FDD) at NASA/GSFC. Until then, all software 
development projects had used FORTRAN as the primary implemen- 
tation language. The Ada development work began with a pilot 
project and a research project that paralleled a production 
FORTRAN development project (References 1 and 2) . After this 
initial Ada experience, several later production projects were 
developed in Ada. For each project, the SEL has collected such 
detailed information as resource data, error data, component 
information, methodology, and project characteristics, so that 
the SEL could study the evolution of the use of Ada itself and 
the actual characteristics of the Ada development process 
(Reference 3) . 

Analysis of the Ada projects has led personnel to document 
lessons learned during the development of Ada projects 
(References 4 through 7) . These lessons have provided valuable 
insight into the impact of Ada, especially in the following 
areas : 
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1. The impact of Ada on the software development process, 

that is, the impact Ada has on such measures as productivity, 
reliability, and maintainability. 

2. The impact of Ada over time, as shown by the differences 
between the first, second, and third Ada projects. 

3. The use of Ada and Ada features as the development environ- 
ment gains more experience in using Ada. 

4. The timeframe for realizing the benefits of using Ada. 


1.1 ADA PROJECTS STUDIED (Chart 2) 

Ada use within the FDD began in January 1985 with the GRODY 
project. As part of the preparation for developing this system, 
personnel first participated in a practice Ada project by 
implementing an electronic mail system (EMS) . These two projects 
actually represent a first Ada experience. 

After the GRODY project was well under way, two new Ada simulator 
projects for the GOES satellite began. GOADA, the dynamics 
simulator, and GOESIM, the telemetry simulator, collectively 
represent a second major experience with Ada. They are 
considered second projects because (1) some team members had 
previous experience in developing systems in Ada and (2) these 
two projects could draw on lessons learned from GRODY. Not only 
were the staffing profiles of the two GOES simulator teams 
different from the GRODY team, but the two GOES teams began using 
additional software tools available within the DEC Ada 
development environment. 
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Late in 1987 and 1988, two more projects, UARSTELS and Build 4 of 
FDAS began; these projects represent a third distinct Ada 
experience. Currently, two more Ada projects are in their early 
stages: EUVEDSIM and EUVETELS , but these projects are very early 

in their lifecycles and are not yet available for study. 


1.2 PROJECT STATUS AND CHARACTERISTICS (Chart 3) 

All totaled, Ada has been used on eight projects in the flight 
dynamics area. Two projects (EMS and GRODY) are completed; three 
(GOADA, GOESIM, and FDAS) are well into system testing; and one 
(UARSTELS) is in the implementation phase. The other two 
projects (EUVEDSIM and EUVETELS) are in the early requirements 
analysis phase. These projects range from nearly 6K to 163K SLOC 
in size, where SLOC is total source lines of code including 
comments, blanks, newly developed code, and reused code. These 
projects have required or are expected to require from 4 to 36 
months to complete and had from three to seven people working on 
them. Although GRODY lasted for 36 months, it should be noted 
that most personnel on this project did not work fulltime on its 
development. The small EMS project could have been completed 
by 2 or 3 people; but since it was part of the Ada training for 
the GRODY project, all GRODY developers participated in some part 
of the EMS project. 


2.0 ADA EVOLUTION 


2.1 TEAM EXPERIENCE AND DEVELOPMENT ENVIRONMENT (Chart 4) 
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Of the eight Ada projects currently under way, six projects have 
progressed far enough to be studied: EMS, GRODY, GOADA, GOESIM, 

FDAS, and UARSTELS. All six of the projects studied have been 
staffed with personnel with a similar level of software develop- 
ment experience, an average of 4 to 5 years. Except for UARSTELS, 
each project also had personnel with a similar level of experi- 
ence in the application. To date, the SEL has not observed any 
impact due to differences in team experience between projects. 

It is also too early to observe any differences in the effect of 
varied levels of Ada experience on project development. The 
number of people who are formally trained in Ada and/or the 
number of those who have been on previous Ada projects is still 
too small. Only the first Ada projects have been completed. 

Some personnel on those projects have contributed to current, 
ongoing projects; however, there are not enough people in the 
environment, even on the most recent Ada projects, to signifi- 
cantly change the ratio of experienced Ada personnel to those 
with no Ada experience. 

The use of tools has evolved somewhat from the first Ada 
projects. The practice Ada project (EMS) had only rudimentary 
tools available (compiler, linker, editor) . GRODY made use of 
the DEC symbolic debugger (SD) , and the Configuration Management 
System (CMS) . All subsequent Ada projects are using these tools 
as well as the Language Sensitive Editor (LSE) . Project person- 
nel have also developed some additional tools in house to create 
package bodies and templates for the associated subunits they 
need to develop. 
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2.2 SOFTWARE CHARACTERISTICS (Chart 5) 


Traditionally, software size has been described in terms of the 
lines of code developed for the system. However, software size 
can be expressed by many other measurements (Reference 8) , 
including 

1. Total physical lines of code (carriage returns) 

2. Noncomment/nonblank physical lines of code 

3. Executable lines of code (ELOC) (not including type 
declarations) 

4. Statements (semicolons in Ada, which include type 
declarations) 

Chart 5 describes the size of the Ada projects in the flight 
dynamics area using these four measurements. The FORTRAN 
project, GROSS, was also included in the summary for comparison. 
The GROSS project is the FORTRAN implementation of the GRODY 
project, and the GRODY/GROSS comparison has been detailed in 
previous papers. Because the GOESIM and UARSTELS projects are 
both telemetry simulators, they are also very similar in terms of 
their functionality. These two Ada projects are estimated to be 
between 75 and 78 thousand lines of code (KSLOC) . In comparison, 
a typical telemetry simulator in FORTRAN consists of 
approximately 28 KSLOC. 

Unless one counts only Ada statements, these figures tell us that 
the use of Ada results in many more lines of code than the use of 
FORTRAN. The increase in lines of code is not necessarily a 
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negative result. Rather, it is simply that the size of the 
system implemented in Ada will be larger than an equivalent 
system in FORTRAN. It is also clear that a precise definition is 
needed of what is a line of code in Ada and what code is included 
in that measurement. 

Throughout the years of developing similar systems in FORTRAN in 
the flight dynamics area, the average level of software reuse has 
been between 15 and 20 percent (Reference 9) . FORTRAN projects 
that attained a 35 percent or higher level of reuse of previously 
developed code are rare. After the first Ada project and with 
only 5 to 6 years of maturing in the environment, Ada projects 
have now achieved a software reuse rate of over 30 percent. This 
is already greater than the typical FORTRAN project. The 
UARSTELS project is expected to consist of more than 40 percent 
reused code. This trend of increasing software reuse is very 
promising. 

2.3 LIFE-CYCLE EFFORT DISTRIBUTION (Chart 6) 

The GROSS project followed the typical FORTRAN life-cycle effort 
distribution (Reference 10) . Specifically, a small amount (8 
percent) of the total effort expended on the project was spent 
during the pre-design or requirements analysis phase of the 
project; 27 percent of the effort was spent during the design 
phase, 40 percent during the code implementation phase; and 25 
percent during the system testing phase. For the Ada projects, 
significant changes to the life cycle have not yet been observed. 
However, the Ada life cycle is changing slightly with each 
project and may soon show a different life cycle than that 
expected for a FORTRAN project. The life cycles for the second 
and third Ada projects are shifting slightly to show more design 
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time required with less system test time. 


As the Ada environment matures and the SEL learns more about Ada, 
the life cycle is expected to continue shifting in the direction 
that the early literature has reported (Reference 11) : more time 

spent in the design phase and less time in the system test phase. 
FORTRAN projects could assume the reuse of the life cycle based 
on past experience. This life cycle cannot be automatically 
reused in Ada, and more study is needed to determine the duration 
and products of each phase of an Ada project. 

With the current projects, the SEL has not observed significant 
changes to the life-cycle phases. However, effort by phase is 
time driven. The SEL also collects effort data by activity 
across all phases. With this data the amount of effort spent on 
such activities as design, coding, and testing is very different 
than the distribution of effort on activities for FORTRAN 
projects. Much more time is spent on design for the Ada 
projects, but more analysis is still needed in this area. 

2.4 ADA COST/PRODUCTIVITY (Chart 7) 

Discussions on Ada productivity are somewhat confusing because so 
many interpretations exist of software size measures in Ada. 
Depending on the measurement used and an individual's 
inclination, one could determine that Ada is either as good or 
not as good as FORTRAN. Using the total lines of delivered code 
as a measure, the first, second, and third Ada projects show an 
improving productivity over time, and they show a productivity 
greater than FORTRAN. However, considering only code statements 
(excluding all comments and continued lines of code) , the results 
are different. An increasing productivity trend remains in the 
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Ada projects over time, but the Ada projects have not yet 
achieved the productivity level of FORTRAN projects. 

Within the flight dynamics environment, many software components 
are reused on FORTRAN projects. Since no Ada components existed 
previously, the first Ada projects were, in fact, developing a 
greater percentage of their delivered code than the typical 
FORTRAN project. Based on a past study by the SEL and on 
experience with FORTRAN projects, personnel concluded that reused 
code costs around 20 percent of the cost of new code (ref 15) . 

The cost of reused code lies in the effort needed to test, 
integrate, and document the reused code in the new system. Using 
this estimate, reusability can be factored into software size by 
estimating the amount of developed code. Because of the 
differences in cost of new and reused code, developed code is 
calculated as the amount of new code plus 20 percent of the 
reused code. With software reusability factored in, the 
productivity for developed statements on Ada projects is 
approximately the same as that for FORTRAN projects. 

The trends in Ada productivity are very positive. Again, lines of 
code must be clearly defined when discussing productivity. Using 
total number of lines as the measurement of software size, Ada 
productivity was always greater than FORTRAN productivity. 

However, due to the greater number of lines of an Ada project 
compared to a similar FORTRAN project, this measure can be 
misleading. 


2.5 USE OF ADA FEATURES (Chart 8) 
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It is difficult to tell whether a given project really used the 
Ada language to its fullest capacity. Different applications may 
or may not need all the features available in Ada. However, in 
an effort to achieve some measurement in the use of the features 
available in the Ada language, the SEL identified six Ada 
features to monitor: generic packages, type declarations, 

packages, tasks, compilable PDL, and exception handling. The SEL 
then examined the code to see how little or how much these 
features were used. 

The numbers of packages and type declarations were normalized to 
the size of the system, and the number of generic packages was 
divided by the total number of packages in the system. As seen 
in chart 8, the use of four of these features has evolved over 
time: generic packages, type declarations, packages, and 

tasking. Compilable PDL and exception handling did not show any 
trends. Perhaps it is too early to see results in these areas. 

The average size of packages (in SLOC) for the first Ada projects 
is much higher than the average size of packages for the second 
and third Ada projects. This is due to a difference in the 
structuring method between the first Ada projects and all 
subsequent Ada projects (Reference 4). The first Ada projects 
were designed with one package at the root of each subsystem, 
which led to a heavily nested structure. In addition, nesting of 
package specifications with package bodies was used to control 
package visibility. Current Ada projects are utilizing the view 
of subsystems described by Grady Booch (Reference 12) as an 
abstract design entity whose interface is defined by a number of 
separately compilable packages, and nesting of Ada packages is 
limited to generic package instantiations. 


F. McGarry 
NASA/GSFC 
9 of 33 



The use of generic packages from the first to the current Ada 
projects seems to be increasing. More tham a third of the 
packages on current projects are generic packages. This higher 
use of generics reflects both a stronger emphasis on the 
development of verbatim reusable components and increased 
understanding of how to effectively utilize generic Ada packages 
within the flight dynamics area. 

The use of strong typing within these software systems is also 
increasing, as measured by the number of type declarations per 
KSLOC. With experience, developers are more comfortable with the 
strong typing features of Ada and are using its capabilities to a 
fuller extent. 

The use of tasking shows the most dramatic evolution over time for 
any particular Ada feature in the flight dynamics environment; 
its use has decreased markedly. The first Ada project, GRODY, 
contained eight tasks. However, from lessons learned on the 
GRODY project, personnel on subsequent Ada dynamics simulator 
projects have reduced that number to four tasks. Current 
telemetry simulator projects require no tasks at all. in the 
area of tasking, experience has shown that extensive use of this 
Ada feature is not appropriate for many applications. Although 

®^tsri£>ive use of tasking might be very appropriate for other 
applications, the use of this Ada feature has definitely changed 
as project personnel have learned to use tasking only in those 
situations that are appropriate. 

2.6 RELIABILITY, ERROR/CHANGE RATE AND CHARACTERISTICS (Charts 9 
and 10) 
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The SEL measures software reliability by the number of changes or 
error corrections made to the software. For Ada projects, 
software error and change rates show a very positive trend. While 
it is too early to observe a definite difference from the FORTRAN 
rates, the reliability of the Ada projects is at least as good as 
that of FORTRAN projects. The error and change rates on the Ada 
projects are also declining over time, a promising trend. The 
types of errors also show an evolution from first through third 
Ada projects. 

On a typical FORTRAN project, design errors amount to only 3 
percent of the total errors on the project. For the first and 
second Ada projects, 25 to 35 percent of all errors were 
classified as design errors, a substantial increase. However, 
for the third Ada project, design errors are dropping signifi- 
cantly and are estimated to be approximately 7 percent. This 
rate is close to what is experienced on FORTRAN projects and 
clearly shows a maturation process with growing expertise in Ada. 

Much of the literature on Ada reports that the use of Ada should 
help reduce the number of interface errors in the software 
(Reference 13) . In our FORTRAN environment, about one-third of 
all errors on a project are interface errors. On our first and 
second Ada projects, the number of interface errors was not 
greatly reduced. Around one-fourth of the errors were interface 
errors. However, with current projects, the SEL is now seeing 
the expected results: interface errors are decreasing. 

"Errors due to a previous change" is a category of errors that 
was caused by a previous modification to the software. The first 
Ada project showed a large jump in the number of these errors 
compared to those using FORTRAN. However, all subsequent Ada 
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projects show a rate for "errors due to a previous change" very 
similar to the FORTRAN rate. Many things probably contributed to 
this initial jump in the error rate: inexperience with Ada, 

inexperience with Ada design methodologies, and a nested software 
architecture that made the software much more complex. Again, 
the error profile is decreasing with the maturity of the Ada 
environment . 

3.0 OVERALL OBSERVATIONS ON THE IMPACT OF ADA (Chart 11) 

In summary, many aspects of software development with Ada have 
evolved as our Ada development environment has matured and our 
personnel have become more experienced in the use of Ada. The 
SEL has seen differences in the areas of cost, reliability, 
reuse, size, and use of Ada features. 

A first Ada project can be expected to cost about 30 percent more 
than an equivalent FORTRAN project (Reference 14) . However, the 
SEL has observed significant improvements over time as a develop- 
ment environment progresses to second and third uses of Ada. 

The reliability of Ada projects is initially similar to what is 
expected in a mature FORTRAN environment. However, with time, 
one can expect to gain improvements as experience with the 
language increases. 

Reuse is one of the most promising aspects of Ada. The proportion 
of reusable Ada software on our Ada projects exceeds the propor- 
tion of reusable FORTRAN software on our FORTRAN projects. This 
result was noted fairly early in our Ada projects, and our exper- 
ience shows an increasing trend over time. 
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The size of an Ada system will be larger than a similar system in 
FORTRAN when considering SLOC. Size measurements can be 
misleading because different measurements reveal different 
results. Ratios of Ada to FORTRAN range from 3 to 1 for total 
physical lines to 1 to 1 for statements. 

The use of Ada features definitely evolves with experience. As 
more experience is gained, some Ada features may be found to be 
inappropriate for specific applications. However, the lessons 
learned on an earlier project play an invaluable part in the 
success of later projects. 
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Ada IMPACTS ON LIFE CYCLE EFFORT DISTRIBUTION 
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• Ada TRENDS ARE IN POSITIVE DIRECTION 
(GROSS/GRODY/GOADA/GOESIM/FDAS) 
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WITH EXPERIENCE 

• NOT ALL FEATURE APPROPRIATE FOR APPLICATION 
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SLOC = TOTAL LINES (INCLUDES COMMENTS/REUSED) 
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MUCH DIFFERENT APPLICATION THAN OTHERS 



ERROR CHARACTERISTICS 
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